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METHOD AND APPARATUS FOR TELECOMMUNICATIONS 
USING INTERNET PROTOCOL 

Abbreviations 

5 The following abbreviations are frequently used in the draft: 

PSTN: Public Switched Telephone Network 

TCP: Transport Control Protocol 

UDP: User Datagram Protocol 

RTP: Real Time Protocol 
10 IP: Internet Protocol 

VoIP: Voice Over IP 

CD: compressor/de-compressor 

CDMA: Code Division Multiplexing Access 

MAC: Medium Access Control 
15 RLC: Radio Link Control 

GSM: Global System for Mobile communication 

GPRS: General Packet Radio Service 



20 1 . Field of the Invention 

This invention relates to an apparatus and method for telecommunications 
using Internet Protocol, and relates especially to an advantageous data 
compression arrangement. 

25 

In a wireless telecommunications network operating a packet switching 
technology, it would advantageous to be able to offer voice and data services 
using the Internet, but the need to transmit the combined headers of Real-time 
Transport Protocol (RTP), User Datagram Protocol (UDP) and Internet Protocol 
30 (IP) in each packet header is a disadvantage. The three headers are respectively 
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20, 8 and 12 bytes per packet, and this 40 byte load is nearly double the voice 
payload of 23 bytes for 20 milliseconds in the voice coding system known as 
GSM FR. It is well known that wireless resource/bandwidth is more expensive 
than landline arrangements, and the overload of the large header load is a serious 
5 drawback. 

2. Brief Description of the Prior Art 

10 One solution as disclosed by S Casner and V Jacobson, "Compressing 

IP/UDP/RTP Headers for Low-Speed Serial Links", RFC2508, ftp://ftp.isi.edu/in- 
notes/rfc2508.txt is to compress the RTP/UDP/IP headers. A protocol is defined 
to compress and decompress the headers, and a reduction to between 2 and 5 
bytes can be achieved. However, a major disadvantage is that if a compressed 

15 packet is lost it must be re-transmitted and the provision of an error-recovery 

facility is essential, and therefore the round-trip-time must be short if quality is to 
be maintained. Further, for many radio networks in which the radio bearer 
capacity is designed for circuit voice service so the link layer PDU size is 
designed to match voice payload, it is difficult to put even 2-5 more bytes into one 

20 Medium Access Control (MAC) block, so that one voice frame with its 

compressed header may have to be transmitted in two MAC blocks, requiring 
extra radio resource or there may be loss of voice quality; yet again, handover 
may change the compression/decompression point in the network, requiring the 
compression state to be re-established, which needs a CONTEXT_STATE 

25 message then a FULL_HEABER packet to be sent, which causes delay and 
packet loss. 



30 



In S Petrack, Ed Ellesson, Framedwork for Compressed RTP, Preliminary 
IETF draft, presented on rem-con mailing list. Feb 1996, 

http://www.mbone.com/lists/rem-conf.1996Ql/0259.html, it is suggested that the 
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two time related fields (RTP sequence number and timestamp) can be compressed 
using a 1-byte "timeclick" number and a separate RTP session control is 
suggested to signal the static parts of the headers out of band, but no details are 
given of how to achieve this. 

5 

3. Summary of the Invention 

According to the invention^ a mobile station for a packet switching radio 
10 network which includes a Voice over Internet Protocol application layer and 
Internet Protocol Stacks including Real Time Protocol, Transport Control 
Protocol, User Datagram Protocol and Internet Protocol layers, further comprising 
a compressor/decompressor to compress voice data, and means to send voice data 
and call signalling data separately and in different data formats to the link layer 
15 and the air interface of the mobile station. 

In one arrangement the compressor/decompressor is arranged between link 
layer (which is above the physical layer in the air interface) and the EP layer, and 
receives both the voice data and the call signalling data. 

20 

In an alternative arrangement the compressor/decompressor is arranged 
between the air interface and the VoIP applications layer, and receives the voice 
data. 

25 Also according to the invention a packet switching radio network 

comprising a plurality of mobile stations as defined above and at least one 
network element in which there is compressor/decompressor means arranged to 
receive signals relating to compressed voice data. 



30 



Further according to the invention a method of operating a packet 
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switching radio network to provide voice services comprising separating the voice 
data from the call signalling and other data, whereby each voice packet containing 
voice data can be provided with compressed or removed RTP/UDP/IP headers. 



5 Yet further according to the invention, a first method of compressing and 

decompressing headers for a packet switching network comprises providing in 
each compressed header a cyclically-reset timeclick_number representing the 
sampling time of the packet payload; increasing the timeclick_number by 1 for 
each sample duration time, counting the reset cycles, and from the count of reset 
10 cycles and a received timeclick_number, providing a sequence number and 
timestamp for providing a decompressed header. 

Yet further according to the invention, a second method of compressing 
and decompressing headers for a packet switching network comprises removing 
15 combined RTP/UDP/IP headers and placing data in RLC/MAC payload; and 

decompressing received packets by use of an internal clock to obtain a timestamp 
value, and increasing the sequence number by 1 for consecutive packets. 



Also according to the invention, a method of establishing a compression 
20 state of a packet header in a packet switching network by making use of call set- 
up information over an out-of-band protocol. 



4. Brief Description of the Drawings 

25 

The invention will now be described by way of example with reference to 
the accompanying drawings in which: 

Figure 1 illustrates a wireless packet switching network based on the 
UMTS model. 

30 Figures 2a and 2b shows two embodiments of the invention in a mobile 



transceiver; 

Figure 3 illustrates an entire communication channel; 

Figures 4a and 4b illustrate alternative compression algorithms; 

Figure 5 shows establishment or re-establishment of compression state; 

5 and 

Figure 6 shows inter-compression point handover. 

5. Description of a Preferred Embodiment of a 
10 Mobile Station and Network 

In Figure 1, a wireless mobile telecommunication system 10 comprises a 
number of Mobile Stations (MS) 12 and a number of base transceiver stations 
(Node B) 14 connected through a RNC (Radio Network Controller) 16 (all in the 
15 Radio Access Network RAN 18) to a packet Core Network (CN) 20 which 

consists of two elements: a SGSN (Serving GPRS Support Node) 22 and a GGSN 
(Gateway GPRS Support Node) 24. The CN is connected via a IP/PSTN Gateway 
26, to the PSTN (Public Switched Telephone Network) 30 and to the Internet 28. 

20 In this Figure the network architecture is based on the UMTS reference 

model. 

Suppose the network 10 operates in packet switch mode. One way to 
implement voice service is to use VoIP technology in which VoIP application 
25 from the mobile station 12 is treated as a general IP application and coded voice is 
decomposed into RTP/UDP/IP packets and transmitted over the air, the RAN 18 
and the CN 20 to Internet 28 or the PSTN 30 via the IP/PSTN gateway 26. 

At a mobile station 12, IP-based call signalling and the Graphical User 
30 Interface of VoIP application can run in the same way as on a normal IP terminal. 
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The voice traffic is sent as a link layer payload with compressed or removed 
RTP/UDP/IP header information, as will be explained in more detail below. 

Referring to Figure 2a, the up-link direction is considered from a mobile 
5 station 60 to the network. In the mobile station there is a VoIP application layer 
68 from which call signalling data is sent to a TCP layer 66 and a UDP/IP layer 
65. Voice data is transmitted to an RTP/UDP layer 67 and an IP layer 65. 

Both call signalling data and voice data in packets are provided to a 
10 compressor 64, which compresses the combined RTP/UDP/IP headers, but the 
compressor does not compress the call signalling data. The two types of packet 
62,63, (compressed and uncompressed) are put in RLC/MAC protocol, and pass 
over the air interface 61. 

15 To receive voice and call signalling data (the downlink direction) the 

process is reversed. 

In the alternative arrangement for a mobile 70 shown in Figure 3b, the 
compressor 74 sends/receives the voice data 63 to/from VoIP application 78 while 
20 call signalling data 62 passes through normal IP layers 75, 76. 

It can be seen that in both arrangements the voice and call signalling data 
are separated. 

25 Figure 3 illustrates a whole system, in which a mobile 60 with its 

compressor 64 is connected through the air interface 61 sequentially to a Radio 
Access Network (RAN) 81 which tunnels or relays data between the air interface 
61 and the Core Network 84, and a decompressor CD 83 in CN 82 connected to 
any IP host 85 via the Internet. 

30 
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In the arrangements shown in Figures 2a, 2b and 3, it is assumed that the 
IP/UDP/RTP header information is not used for routing etc, from the mobile 
station 60 to the CD 83 in CN 84; instead all data including voice packets are 
relayed/tunnelled. It is assumed that the packets are delivered in sequence 
5 between the mobile 60 and the CD 83. It is further assumed that some mechanism 
will be able to distinguish compressed (speech) packets from normal 
(uncompressed) packets, and this distinction can be maintained until CN 84 is 
reached. 

10 The arrangement described may achieve a level of radio efficiency which 

is of a similar level to a circuit switched voice service provided by wireless 
telecommunications systems such as GSM. 

It is a further advantage that no error recovery mechanism is needed, and 
15 there is no inter-packet dependency for decompression, so packet loss does not 
cause malfunction of the compression point. 



The VoIP applications 68, 78 run as if they are accessing a normal IP 
network although the voice packets are treated differently along part of their 
20 journey - from the MS 60 to CN 84. Also, from the viewpoint of the other IP 

endpoint 85 (a user terminal or a IP/PSTN gateway), the elements in the RAN 81 
(MS 60, Node B and RNC 80) are treated as a set as a endpoint, because the voice 
frames (data 63) need to travel a relatively long way before being RTP-framed at 
CD 83. 

25 

General benefits of the arrangement are that there is higher compression 
gain and saving of resources; that the system operates when the round-trip-time 
between compression and decompression is long; and that the benefits from IP- 
based call signalling can be kept. 



30 
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6. Description of Two Preferred Algorithms 



There are two compression algorithms for DVUDP/RTP headers, one can 
be characterized as a "best-effort lossy compression" and another one can be 
5 characterized as "Zero header compression". Both algorithms are based on the 
fact that the DVUDP/RTP headers are not used between MS 64 and CN 84. 



6a. First Preferred Algorithm 

10 The objective is to break up the interdependency of the compressed 

packets. Instead of sending relative values in the compressed headers (by 
differential coding), absolute values (timeclick numbers) are sent as suggested by 
Petrack. As there is no inter-relationship between compressed RTP packets, 
packet loss will not stop decompression from operating. 

15 

Using the first algorithm the compressed header can be only 1 byte, 
in comparison with 2 to 5 bytes in a known arrangement. The most 
important information in RTP header, the two time related fields - 
timestamp and sequence number, need to be retained. As pointed 

20 out in the paper by Petrack referred to above, these two fields can 

be replaced by a "timeclick number" (in one byte). This number 
assists the decompressor to put a proper timestamp (reflecting the 
sampling time at the mobile station 60) and sequence number. The 
publication suggests that instead of the conventional timestamp and 

25 RTP number, a single 1 byte "timeclick" number is sent with each 

packet. However, in the prior publication there was no disclosure 
of how to recover the timestamp and sequence number or how to 
establish compression states out of band. 



30 



It is assumed that there is only one VoIP session requiring 
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compression per terminal, thus no CID (Context ID) bits is 
required. The M bit in RTP header is kept and transmitted with 
each compressed packet. 

5 Compression-state, first algorithm. The compression state contains the 

following information for a call (consisting of two RTP sessions) to be 
compressed: for each call-end: DP address, two port numbers (sourcing and 
incoming), SSRC etc. for the call: the codec used and its parameter (e.g. 
sampling rate and sample duration). The codec for both directions is assumed to 
10 be the same. (If not then need to store them separately). 

The establishment of the compression-state is via an out-of-band protocol, 
which can work together with the call signalling protocol, and will be described 
later. This protocol will also help to migrate the state information from one CD to 
15 another one in the case of handover between CDs. 

Compression process, first algorithm. Through the compression, three 
fields will be preserved in a nearly lossless way: timestamp, sequence number and 
the M bit. A byte (8 bits) is used for the compressed header: the first bit is used 
20 for the M bit, and the other 7 bits for timeclick_ number, which represents the 
sampling time of the voice payload contained in the packet. It is increased by 1 
every sample duration time, e.g. 20 ms for GSM6. 10 coding. It will continue to 
be increased even in the silent period when no packets are actually sent out. 

25 The fields whose information may become inaccurate through the 

compression are: 

The packet ID in IP v4. It is assumed that the packet ID field 
always increases by 1 so it does not need to be communicated . 
30 When packet loss is detected the ID value is set accordingly. As 
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not all packet-loss can be detected so the ID value may become 
inaccurate. 

UDP checksum field. The checksum field is not used (set to 0) 
5 from mobile terminal 60. If it is used on the down-link direction, it 

is set to 0 by the CD in the network (and then the end-to-end error 
detection for applications that require it is disabled). Thus the error 
correction using the UDP checksum will be disabled. 

10 - RTP CSRC list. For the uplink direction, the CSRC list should 

always be empty. For the downlink direction, it may change (e.g. 
in the case of conference call). For 2-party call, it will be 
unchanged (empty). 

15 - Sequence number. In the case of packet loss between the mobile 

station and the RTP proxy, and the decompressor failed to detect it, 
the sequence number recovered by the RTP proxy is incorrect, 
which may influence the accuracy of the statistical result of packet 
loss rate. 

20 

There are two modes of accessing the compression service. One is 
accessed by the VoIP application directly (as shown in Figure 3(b)), by-passing 
the transport and network layers. The obvious benefit is the efficiency, but it may 
25 need some change of the application or need a transport layer wrap up. The 
service access primitive for the compressor can be: 

compress (M, timeclick_number, voicepayload) 

30 It is straightforward to generate a compressed RTP packet with these three 
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data items. 

Alternatively the compression service can be accessed by the network 
layer in a transparent way (as shown in Figure 2(a)), thus all upper layers are 
5 unknown about the compression. In this case, upon receiving a packet from upper 
layer, it checks the fields of source/destination IP and port number also the source 
SSRC. These five fields will identify a RTP session and by checking these field 
against the compression-state table, it is decide either to compress the packet (if it 
is a RTP packet whose compression state already established), or treat it like non- 
10 RTP, normal packet. If it is a RTP packet to be compressed, the timestamp field 
is mapped to a timeclick-number. Then the above service primitive can be called. 

For the downlink direction, if the UDP checksum is used (non-zero), it 
will be ignored. 

15 

After a compressed RTP packet is generated, it is put in a link layer packet 
together with a marker telling it is a speech packet. Other non-compressed packet 
will be put into a link layer packet marking itself as general data packet. 

20 Decompression process, the first algorithm. 

Except for the time-related RTP header fields, recovery of the other fields 
are from the compression state using a similar approach to RFC 2508. 

25 For the timestamp field: the major problem to solve is that the field for 

timeclick number is only 7 bits. The click counting will continue and can easily 
wrap around (reset periodically) during a single telephone call). During a silent 
period, if there is no packet sent by the compressor, the time elapsed for this silent 
period (in terms of how many cycles passed), must be detected. 

30 
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In the first algorithm according to the invention, a computer clock at the 
CD 84 is used to count the cycles and the timeclick number is used, with reference 
to the clock reading, to set the timestamp field. The clock can run at a coarser 
granularity. For example it can be increased by 1 for every T/4 period assuming 
5 the maximum jitter is less than T/4, which is a safe assumption, where T is the 
time period of a cycle represented by 7 bits. It is usually several seconds, 
depending on the codec parameters. 

Turning now to the sequence number, this number is normally increased 
10 by 1 for each consecutive packet. It is mainly used to reflect the packet loss. In 
the first algorithm according to the invention, a heuristic method is used to detect 
packet loss by checking both the increases of timeclick number and the M bit. If 
the timeclick number is increased by a small number other than one (say two, 
three etc.) but the M bit is not set, then there is likely some packet-loss. In this 
15 case the sequence number is increased by the difference of the timeclick number. 
In the case of the packet that carries the set M bit gets lost (then the bigger 
increase of timeclick number is normal, as it is silent period), the sequence 
number should still be increased by 1. The probability for this situation to happen 
is quite small. Even if this happens and the sequence number is increased by . 
20 mistake, it will slightly influence the statistic result of packet-loss rate perceived 
by the other RTP end (a few more packets are reported to be lost). 

Denotation: 

sd: sample duration, the value should come from the call setup procedure, 
25 e.g. 20ms (voice in each packet) 

sr: sample rate, the value should come from the call setup procedure, e.g. 
8000 

nb: number of bits used for the timeclick number 
TSlast: Timestamp number for the previous packet 
30 TSthis: Timestamp number for this packet 
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WTlast: Wallclock reading for the previous packet 
WTthis: Wallclock reading for this packet 

TNlast: Timeclick number of previous packet in compressed header 
TNthis: Timeclick number of this packet in compressed header 
SNlast: RTP sequence number of previous packet 
SNthisL: RTP sequence number of this packet 

T: the time period represented using nb bits (a cycle period), in units of 
sample duration (sd) 
T = 2**nb 

M: the value of the "M" bit, in compressed header 

Calculating the timestamp and sequence number: 

TSthis = Tslast + 1, if M = 0 and delta_tick = 1 

= Tslast + (delta_cycle*(2**nb) + delta_Jick)*sd*sr/1000, 
15 otherwise where: 

delta_tick = (T + Tnthis - Tnlast) mod T 
delta_wtick = Wtthis-Wtlast mod T 
deita_cycie = Cwtthis-Wtlast)/T/*integer part*/ 

delta_cycle = delta_cycle' -1, if delta wtick < delta tick and delta tick- 
delta wtick >= T/2 

= delta_cycle' +1, if delta_tick < delta_wtick and delta_wtick- 

delta_tick>= T/2 
= delta_cycle\ otherwise 
Snthis = Snlast + delta_tick, if delta_tick !=1 and delta_tick < 4 and M !=1 

6b. Second Preferred Algorithm 

The second algorithm for header compression is now described; the header 
30 may be zero. 



5 
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20 
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In some cases, for example, GPRS (General Packet Radio System, an 
overlay packet network over GSM system), the radio bearer channel is designed 
in such a way that it is hard to put any extra header information together with 
speech data. Thus we would like to investigate if it is possible to transmit voice in 
5 "raw" format (speech only), but still keep most of the benefits from IP telephony 
(e.g. IP based call signalling thus enable CPL, web-based call etc). 

The basic idea of this solution, as shown in Figure 4b, is that considering 
that the path between mobile station 60 and CN 84 is over a controlled packet 
10 network (over frame relay or ATM, for example) and certain QoS will be 

provided (no mis-ordering, the jitter and packet-loss-rate are small so that the 
voice quality will not suffer on this path), it is possible completely to remove the 
IP/UDP/RTP headers between mobile station and CP and use a box called RTP 
agent as the decompressor in CN. 

15 

In this case the RTP agent (up line direction) performs a role 
similar to the IP/PSTN gateway: for the up link direction, the 
voice frames from a mobile station are transmitted without any 
IP/UDP/RTP headers, in a way very close to the circuit-mode 
20 voice in wireless networks, e.g. in GSM, (but is over a "good" 

quality packet network), up to the RTP agent which adds proper 
headers and sends them off to VoIP networks. On the downlink 
direction, the RTP agent strip off the headers and transmit them up 
to the mobile station. 

25 

Using the second algorithm, the benefit of IP based call signalling and 
service creation is retained. At the same time there is the benefit of high radio 
resource efficiency. On the other hand, the mobile terminal may lose some 
capability relying on RTP header information; for example to find the packet- 
30 loss-rate and packet delay, and the play buffer may be adjusted accordingly. 
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The major differences between the first and second algorithms are that, 
when using the second algorithm: 

On the mobile station, the VoIP application loses the chance of 
using any time-related information in RTP header. For example to 
detect the packet-loss and calculate the jitter. Note that the 
compression itself will not introduce extra packet-loss and jitter. It 
would be difficult to generate proper RTCP packets but can ask 
RTP agent to do this job on its behalf. 

From the viewpoint of the other IP endpoint of the call (a user 
terminal or gateway), the packet loss detected by the RTP agent 
(and reflected in the fields of sequence number and timestamp) 
may be less accurate than the first algorithm. 

The way that the CD in the second algorithm adds on (up link) and strips 
off (down link) IP/UDP/RTP headers is similar to that used in a general IP/PSTN 
media gateway. The differences are: 



20 - The general media gateway normally has two network interfaces: 

one for PSTN and another one for packet network (e.g. IP, ATM). 
It translates media between circuit-mode and packet-mode. RTP- 
agent has two network interfaces both of which are for packet 
network. 

25 

In general media gateway, the voice coming from the PSTN side is 
continuous and its rate is constant. In our case, as voice frames are 
transmitted over packet network on both sides, it needs to do more; 
to try to detect the packet loss in order to put on correct sequence 
30 numbers and timestamps by examining the inter-arrival time of the 
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packets from RAN side; it may need to send RTCP packets on 
behalf of the mobile terminal. 

Compression-state, second algorithm. This is the same as in the RTP- 
proxy approach. 

Compression process, second algorithm. The compression process is 
very simple: it just strips off any header and puts the speech data only into 
RLC/MAC messages. The service access primitive for the compressor can be: 

compress (voicepayload) 

Like in RTP-proxy approach, the compression service, at the terminal, can 
be accessed by the network layer in a transparent way. In this case, upon 
receiving a packet from the network layer, it checks the fields of source/dest IP 
and pot number, also the source SSRC. These five fields will identify a RTP 
session and by checking these fields against the compression-state table, it is 
decided either to compress the packet (if it is a RTP packet whose compression 
state already established), or treat it like non-RTP, normal packet. If it is a RTP 
packet to be compressed, the headers are strip off and the above service primitive 
can be called. 

For the downlink direction, the CD in the network checks each packet to 
see if it belongs to a RTP session being compressed. If yes the RTPAJDP/IP 
headers are stripped off and the speech data is put into the payload of, for 
example, the tunnelling protocol addressed to the right mobile terminal. 

Decompression process, second algorithm. At the decompressor in the 
network (CD 84), a computer clock is used. As for the first algorithm, the major 
problem is how to recover the time-related fields. There are two ways to do this:- 
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(a) - The decompressor checks at the beginning of every sampling 

duration period (the period covered by the speech frame(s) carried 
by an RTP packet; for example it will be 20ms if each RTP packet 
carries one GSM6.10 speech frame) to see if there is any 
5 compressed speech packet coming from RAN. If "yes" the 

decompressor adds IP/UDP/RTP headers on the packet. The 
decompressor maintains a small buffer for incoming speech 
packets from RAN to smooth out the jitter. 

10 - The decompressor obtains the timestamp value from the internal 

clock (translated to the sampling time format as used in RTP). The 
sequence number is increased by 1 for each packet. 

Alternatively, the decompressor checks the inter-arrival time of 
each compressed packet arriving at the RAN side to guess if there 
is any packet-loss, considering the variation of delay and the 
possibility of silent period. After this analysis is performed, if the 
packet just arrived is thought as the consecutive speech packet of 
the previous one, then timestamp is increased in the same way as at 
the source (added by a constant value, which is determined by the 
coding scheme used, on the top of the timestamp value of the 
previous one). The sequence number is added by one on the top of 
the sequence number of the previous packet. If a packet loss is 
inferred then the sequence number and timestamp will be increased 
accordingly to reflect the gap. If a long gap is detected and a silent 
period is inferred, the sequence number is added by 1 but the 
timestamp need to reflect the gap. 

While the first and second preferred algorithms have been described with 
30 reference to a packet switching radio network, both algorithms may also be 



(b) - 

15 



20 
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applied in other circumstances where the following features hold: 

The first leg between a mobile station and IP network is a point-to- 
point like connection over which the IP headers are not used. 

5 

The first leg of connection guarantee in-order delivery and small 
jitter. Some header inaccuracy pointed out before is acceptable for 
the application. 

10 

7a. A preferred process of compress-state establishment 
and re-establishment 

The compression-state establishment process is used for several 
1 5 purposes/occasions : 

At the beginning of a RTP session, the compression-state needs to 
be established to start compression and decompression. 

20 - When inter CDs handover happens, the compression-state needs to 

be migrated to the new CD from mobile terminal and/or from the 
old CD. 

The compression-state contains the following information: IP address and 
25 SSRC for both call ends, two pairs of RTP (UDP) port numbers, payload type, 
sampling rate, sample duration, etc. 



30 



It is assumed that the voice coding for both directions are the same, 
otherwise they need to be stored separately. 
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The compression state establishment and re-establishment are done using 
an out-of band protocol, which is shown in Figure 5, which shows a mobile 
station compressor 90 connected to a VoIP call control layer 92 under third party 
control; a serving network CD 94 and another network compressor 96; and the 
5 network CDs 94, 96 are connected directly by an out-of-band link 98, and are also 
connected to a VoIP call control layer 100 and a mobility management layer 102 
under third party control. 

All the CDs 90, 94, 96 are in reality compressor/decompressors. 

10 

The CDs 90 at the mobile station and 94 in the network have a control 
interface. Both CDs listen on a known port to accept instructions to start/stop 
compression and receive state information from the third party. Typically the 
instruction and information come from the voice application at MS and/or 
15 signalling gateway (e.g. a 4.323 Gatekeeper or SIP (Session Initiation Protocol) 
server) inside network. (Assume that the IP address of the serving CD is known 
to the signalling gateway.) 

There are six messages defined between CD and a third party control or 
20 between two CDs (not including the acknowledgement messages): 

1. STATE_START. This message indicates that a new compression 
session and its state is to be established. It should contain an 
identity of the MS being involved in the session. As an option it 

25 can contain a full (uncompressed) RTP packet so that the 

compression state information can be extracted from it. 

2. STATEJNPUT. This message provides or modifies values of 
state attributes. It contains a list of (attribute_name, value) pair. 



30 
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3. STATEJENQRY and STATE_ENQRY_RPL. These two 
messages can be used to inquiry the state information and to know 
if it is ready to perform compression/decompression tasks. 

4. STATE_HANDOVER. This message informs a current serving 
CP to send state information to a new CP, or asks a new serving 
CP to acquire state information from a previous serving CP. The 
message contains information bout the IP address of old and new 
CPs and the identity of the MS involved. 

5. STATE_STOP. This message deletes a compression state. A 
compression can also be deleted by compressor itself when 
necessary. 



15 The message STATE_INPUT is also used between the compressor 90 at 

MS and the CD 94, 96 in network to exchange state information. So the 
information available at one end will be available at the other end by using this 
protocoi. 

20 The messages STATE_INPUT and STATEJENQRY are also used for 

moving state information from one CD to another in the case of handover. Apart 
from the state elements listed above, some extra information such as local clock 
reading is also exchanged to the new CD. 

25 It is allowed for the compressor to pick up values or use default values for 

some attributes in some circumstances. 



30 



This process also supports the state re-establishment between CDs at MS 
and in network. This is necessary when the state information is damaged or lost at 
one side. Once the compressor at CD or MS detects the miss or incompleteness of 
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state information, it can use STATE_ENQRY to obtain the state information from 
the other end. 

While the inventive process of establishing or re-establishing compression 
state has been described with reference to a packet switching radio 
telecommunications network, the process may also be used for any compression 
process for a connection oriented application such as VoIP and multimedia 
sessions. 

8. Two preferred processes for handover between 
two compression-points 

One problem to use the compression scheme presented in RFC2508 within 
wireless networks is the impact of mobility. When a handover occurs, it is 
possible that the serving CD will change. So the compression states stored in the 
CD before handover have to be moved to or re-established at the new CD. 

Two alternative approaches are proposed to cope with this problem: 
• Firstly, we can arrange some communication between two CDs so that 
they can exchange compression states, as shown in Figure 6 in which a 
mobile station having a compressor 104 is handed over from a serving 
CD in network 106 to a new CD 108 in network. The serving and new 
CDs 106, 108 are provided with an out-of-band communication 
channel 110. 

One way is to share the compression state information among a group of 
CDs (which may potentially become the serving CD after handover), so 
that when handover happens the necessary compression context already 
ready in the new CD. The cost of this method is the CPU time and 
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memory required to receive/store the context which may not be used at 
all. 

Another way is to exchange the contact information during handover. To 
apply this approach, we need the co-operation from the handover 
mechanism so that the exchange of compression states information can be 
triggered when the CD is changed. 

A third way is to make use of soft-handover feature available in CDMA 
networks. The exchange of context can be performed during soft- 
handover period. This approach requires the co-operation from the radio 
network so that the two CDs can be informed when a soft-handover 
happens. 

To allow the decompression process at the new CD, the exchange of 
compression-state information should include the timestamp value and 
sequence number value in the last decompressed RTP packet by the 
previous CD. The two computer clocks at the previous and new CD need 
not be synchronized. When the new CD start to serve the RTP session 
handed over, it read its own clock and uses the reading as the clock 
reading for the last packet. 

• Secondly, as in UMTS and GPRS situation, the user IP will not be 
used until the point to leave CN for backbone network(a tunnelling 
protocol is used to transport user packet between BSS and CN). 
Therefore we can make use of this feature and put CP at the edge of 
CN, for example at GGSN so that the CP is transparent to the 
handover. In particular, by moving the CP into CN, the CP and the 
IP/PSTN gateway, which is required to make use the VoP service 
network, can be integrated. The drawback of this approach is the 
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possible performance bottleneck at the CP in network. 



Several modifications of the present invention will become readily 
apparent to those skilled in the art in the light of the foregoing disclosure. 
Therefore, the scope of the present invention should be interpreted from the 
following claims, such claims being read in the light of the disclosures. 



